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Abstract 


This document recommends using one UDP port pair for both 
communication directions of bidirectional RTP and RTP Control 
Protocol (RTCP) sessions, commonly called "symmetric RTP" and 
"symmetric RTCP". 
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Introduction 


TCP [RFCO793], which is inherently bidirectional, transmits and 
receives data using the same local port. That is, when a TCP 
connection is established from host A with source TCP port "a" toa 
remote host, the remote host sends packets back to host A’s source 
TCP port "a" 


However, UDP is not inherently bidirectional and UDP does not require 
using the same port for sending and receiving bidirectional traffic. 
Rather, some UDP applications use a single UDP port to transmit and 
receive (e.g., DNS [RFC1035]), some applications use different UDP 
ports to transmit and receive with explicit signaling (e.g., Trivial 
File Transfer Protocol (TFTP) [RFC1350]), and other applications 
don’t specify the choice of transmit and receive ports (RTP 
[RFC3550]). 


Because RTP and RTCP are not inherently bidirectional protocols, and 
UDP is not a bidirectional protocol, the usefulness of using the same 
UDP port for transmitting and receiving has been generally ignored 
for RTP and RTCP. Many firewalls, Network Address Translators (NATs) 
[RFC3022], and RTP implementations expect symmetric RTP, and do not 
work in the presence of asymmetric RTP. However, this term has never 
been defined. This document defines "symmetric RTP" and "symmetric 
RTCP". 


The UDP port number to receive media, and the UDP port to transmit 
media are both selected by the device that receives that media and 
transmits that media. For unicast flows, the receive port is 
communicated to the remote peer (e.g., Session Description Protocol 
(SDP) [RFC4566] carried in SIP [RFC3261], Session Announcement 
Protocol (SAP) [RFC2974], or Megaco/H.248 [RFC3525]). 


There is no correspondence between the local RTP (or RTCP) port and 
the remote RTP (or RTCP) port. That is, device "A" might choose its 
local transmit and receive port to be 1234. Its peer, device "B", is 
not constrained to also use port 1234 for its port. In fact, sucha 
constraint is impossible to meet because device "B" might already be 
using that port for another application. 


The benefits of using one UDP port pair is described below in 
Section 4. 


Conventions Used in this Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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3. Definition of Symmetric RTP and Symmetric RTCP 


A device supports symmetric RTP if it selects, communicates, and uses 
IP addresses and port numbers such that, when receiving a 
bidirectional RTP media stream on UDP port "A" and IP address "a", it 
also transmits RTP media for that stream from the same source UDP 
port "A" and IP address "a". That is, it uses the same UDP port to 
transmit and receive one RTP stream. 


A device that doesn’t support symmetric RTP would transmit RTP from a 
different port, or from a different IP address, than the port and IP 
address used to receive RTP for that bidirectional media steam. 


A device supports symmetric RTCP if it selects, communicates, and 
uses IP addresses and port numbers such that, when receiving RTCP 
packets for a media stream on UDP port "B" and IP address "b", it 
also transmits RTCP packets for that stream from the same source UDP 
port "B" and IP address "b". That is, it uses the same UDP port to 
transmit and receive one RTCP stream. 


A device that doesn’t support symmetric RTCP would transmit RTCP from 
a different port, or from a different IP address, than the port and 
IP address used to receive RTCP. 


4. Recommended Usage 


There are two specific instances where symmetric RTP and symmetric 
RTCP are REQUIRED: 


The first instance is NATs that lack integrated Application Layer 
Gateway (ALG) functionality. Such NATs require that endpoints use 


symmetric UDP ports to establish bidirectional traffic. This 
requirement exists for all types of NATs described in Section 4 of 
[RFC4787]. ALGs are defined in Section 4.4 of [RFC3022]. 


The second instance is Session Border Controllers (SBCs) and other 
forms of RTP and RTCP relays (e.g., [TURN]). Media relays are 
necessary to establish bidirectional UDP communication across a NAT 
that is ’Address-—Dependent’ or ’Address and Port—Dependent’ 

[RFC4787]. However, even with a media relay, symmetric UDP ports are 
still required to traverse such a NAT. 


There are other instances where symmetric RTP and symmetric RTCP are 
helpful, but not required. For example, if a firewall can expect 
symmetric RTP and symmetric RTCP, then the firewall’s dynamic per- 
call port filter list can be more restrictive compared to asymmetric 
RTP and asymmetric RTCP. Symmetric RTP and symmetric RTCP can also 
ease debugging and troubleshooting. 
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Other UDP-based protocols can also benefit from common local transmit 
and receive ports. 


There are no known cases where symmetric RTP or symmetric RTCP are 
harmful. 


For these reasons, it is RECOMMENDED that symmetric RTP and symmetric 
RTCP always be used for bidirectional RTP media streams. 


5. Security Considerations 


If an attacker learns the source and destination UDP ports of a 
symmetric RTP or symmetric RTCP flow, the attacker can send RTP or 
RTCP packets to that host. This differs from asymmetric RTP and 
asymmetric RTCP, where an attacker has to learn the UDP source and 
destination ports used for the reverse traffic, before it can send 
packets to that host. Thus, if a host uses symmetric RTP or 
symmetric RTCP, an attacker need only see one RTP or RTCP packet in 
order to attack either RTP endpoint. Note that this attack is 
similar to that of other UDP-based protocols that use one UDP port 
pair (e.g., DNS [RFC1035]). 
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